home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1996 #15
/
Monster Media Number 15 (Monster Media)(July 1996).ISO
/
games_du
/
dn3ded02.zip
/
DN3DED02.TXT
next >
Wrap
Text File
|
1996-05-25
|
39KB
|
1,216 lines
THE UNOFFICIAL
DUKE NUKEM 3D
EDITING
FAQ
[need ASCII logo here - anyone?]
Release v0.2 - Request For Comments II
Last Updated: May 20, 1996
Written by: Klaus Breuer (sz0759@rrze.uni-erlangen.de)
Chapter 1
Happy lawyer dept.
1.1 Disclaimer
This FAQ is to aid in informing the public about creating
additional levels for the Game Duke Nukem 3D, by 3D Realms. In no
way should this promote your killing yourself, killing others, or
killing in any other fashion. Also, it should not promote the
building of real-world death-traps :)
Additionally, Klaus Breuer claims NO responsibility regarding ANY
illegal activity concerning this FAQ, or indirectly related to
this FAQ. The information contained in this FAQ only reflects 3D
Realms indirectly, and questioning 3D Realms regarding any
information in this FAQ is not recommended.
1.2 Trademark information
All specific names included herein are trademarks and are so
acknowledged:
3D Realms, Duke Nukem, IBM, Microsoft and MS-DOS. Any trademarks
not mentioned here are still hypothetically acknowledged.
1.3 Copyright notice
This article is Copyright 1996 by Klaus Breuer. All rights
reserved.
You are granted the following rights:
1. To make copies of this work in original form, so long as
1.1. the copies are exact and complete;
1.2. the copies include the copyright notice and these
paragraphs in their entirety;
1.3. the copies give obvious credit to the author, Klaus
Breuer;
1.4. the copies are in electronic form.
2. To distribute this work, or copies made under the
provisions above, so long as
2.1. this is the original work and not a derivative
form;
2.2. you do not charge a fee for copying or for
distribution;
2.3. you ensure that the distributed form includes the
copyright notice, this paragraph, the disclaimer of
warranty in their entirety and credit to the
author;
2.4. the distributed form is not in an electronic
magazine or within computer software (prior
explicit permission may be obtained from Klaus
Breuer);
2.5. the distributed form is the NEWEST version of the
article to the best of the knowledge of the
distributor;
2.6. the distributed form is electronic.
You may not distribute this work by any non-electronic media,
including but not limited to books, newsletters, magazines,
manuals, catalogs, and speech. You may not distribute this work
in electronic magazines or within computer software without prior
written explicit permission.
These rights are temporary and revocable upon written, oral, or
other notice by Klaus Breuer. This copyright notice shall be
governed by the laws of the Federal Republic of Germany.
If you would like additional rights beyond those granted above,
write to the author at "sz0759@rrze.uni-erlangen.de" on the
Internet.
Chapter 2
Introduction
2.1 *A word from Klaus Breuer*
Well, here's the v0.2 version of the FAQ, still released as an
RFC (Request For Comments) - so let's hear your comments :)
Since this is only v0.2, there will be lots of gaps, omissions,
errors and -gasp- typos.
I've added quite a few how-tos, I'll add to the editor handling
in the next release.
2.2 *About the "UnOfficial" DUKE NUKEM 3D EDITING FAQ*
Welcome to the release v0.2 of the "UnOfficial" DUKE NUKEM 3D
EDITING FAQ.
What does that mean? Version 0.2 is the second RFC release,
"UnOfficial" means absolutely nothing, DUKE NUKEM 3D is the name
of the game, Editing is what the FAQ is all about and FAQs are
[F]requently [A]sked [Q]uestions.
Here's how revision classification works. If a new version of
the FAQ only has a small amount of information changed or added,
the version number is increased by 0.1. This is called a "minor
revision."
If a new version of the FAQ has a substantial amount of new
information changed or added, the version number is increased by
0.5. This is called a "standard revision."
If a new version of the FAQ has a huge amount of added or changed
information, major parts of the FAQ are rearranged, or major
parts of the FAQ are rewritten, then the version number is
increased by 1.0. This is called a "major revision."
Currently we're still in the 0.x stage, meaning a very
preliminary FAQ. As soon as we have amassed sufficient info in
here, I'll update the version number to 1.0.
You may be wondering why chapter headings are enclosed in either
[]'s, ()'s, or **'s. The definition of these is as follows:
[] Chapters enclosed in brackets mean that the
information contained in the chapter has not been
updated in this or the previous FAQ.
() Chapters enclosed in parenthesis mean that the
information contained in the chapter has not been
updated since the previous FAQ.
** Chapters enclosed in asterisks means that the
information contained in the chapter is new or has
been updated for the current version of the FAQ
you are reading.
If chapter headings are not enclosed in one of the above ways, it
means that it doesn't contain any information yet - ## please
help fill in the gaps!
Also, feel free to suggestion additional topics and questions,
even (especially?) if you don't know the answers to them.
Also, ##'s are at times found in the text - these denote
questions I urgently need help on, and any feedback is especially
appreciated.
2.3 *Getting the "UnOfficial" DN3DE FAQ*
The "UnOfficial" DN3DE FAQ is posted every month (or earlier if a
new version is released) on the following Usenet groups:
(1) comp.sys.ibm.pc.games.action
(2) alt.games.duke3d
The "Subject:" line of the post will be "'UnOfficial' DN3D
EDITING FAQ v??.??" where "??.??" is the version number of the
FAQ.
New releases of the "UnOfficial" DN3D EDITING FAQ will be
uploaded to internet ftp sites as soon as I find suitable sites.
The file name of the upload will be "dnefaq??.faq" where "??" is
the version number of the FAQ.
ATTENTION: ALL BBSes, Compuserve, America Online, GEnie, and all
other information services. PLEASE conform to the naming
standard of the "UnOfficial" DN3D EDITING FAQ when placing this
file on your system.
2.4 (Adding to the FAQ)
If you want something added to the FAQ, please send E-mail to
"sz0759@rrze.uni-erlangen.de" (no quotes), explaining what your
addition is.
It will be reviewed, and if accepted, added to the next FAQ
version. In the E-mail, please supply your name and E-mail
address.
Please note that all submissions to the FAQ become the property
of the author (Klaus Breuer) and that they may or may not be
acknowleged.
By submitting to the FAQ, you grant permission for use of your
submission in any future publications of the FAQ in any media.
The author reserves the right to omit information from a
submission or delete the submission entirely.
2.5 (The DN3D EDITING mailing list)
## There is no such list yet, but hopefully somebody will pop up
who will run one...
2.6 (Acknowledgments)
I'd like to thank 3D Realms for bringing out such an astonishing
game! After two years, we finally seem to have a DOOM killer :)
ALPHABETICAL ORDER:
Thomas Mueller (tsmuelle@cip.informatik.uni-erlangen.de)
He found out lots of basic workings like
Teleoprters, Swimming Pools, etc and put me on the
right track in regard to sector tags.
THANK YOU! If, for some reason, I did miss you, PLEASE send me
e-mail!
Finally, I'd like to thank everyone who reads this FAQ, you are
what the FAQ is for!
2.7 (Accurate information)
An attempt has been made to make the information in this FAQ as
accurate as possible. Unfortunately, due to the fact that the
game was recently released, and updates, add-ons, and new
information are being worked on each second, it's hard to keep
up.
2.8 *Help with new levels*
If you are building a new level and are experiencing trouble,
feel free to contact me about it. Chances are that you are not
the only one with this problem, and I can add it to the FAQ.
Also, your particular difficulty could be an interesting side-
effect of something else, and others might want to hear about it
as well.
However, *please* read the FAQ fully before asking me about
anything :)
Chapter 3
Preliminary information
3.1 Intended audience for this chapter
3.2 The basics
3.3 What a map consists of
3.4 BUILD basics: the BUILD.EXE editor
3.5 2D mode
3.5.1 Creating a new sector
3.5.2 Creating an internal sector
3.5.3 Erasing a sector
3.6 3D mode
Chapter 4
Planning and designing a level
4.1 Before starting
4.2 Pros and cons of using real-world maps
4.3 *Typical mistakes to avoid*
This section contains, in no particular order, common errors
which you should avoid:
4.3.1 *Crossed lines*
By this I mean bounding lines from the same sector crossing each
other. While the game will aloow this, it usually looks bad.
4.3.2 *Overlaying lines*
Overlaying lines very often leads to mysterious graphics glitches
(a door texture suddenly spilling onto the floor is a typical
example).
Rather place the lines very close to each other (using Grid lock
off).
Chapter 5
A walkthrough to creating a simple level
5.0.1 Some thoughts on good level design
5.1 Creating a new map
5.2 The grid
5.3 Creating a room
5.4 Changing the floor and ceiling heights
5.5 Changing the look of walls (textures)
5.6 Adding another room
5.7 Adding a pedestal (inner sectors)
5.8 Sprites and objects
5.9 The enemy appears
5.10 Player starting points
5.11 Save-n-go
Chapter 6
How to...
6.1 *The basics*
6.1.1 *Abbreviations*
In order to easily describe tags and the like, I use some
abbreviations:
[x,y] The tags of a sprite or wall: x is the hi-tag, y
the lo-tag.
Example: [0,34] describes a hi-tag of 0 and a lo-
tag of 34.
(x) Tile number (refers to sprites, too).
Example: (621) is the camera sprite.
S Sector effector tag
Example: S [100,256] means to insert a Sector
effector with the hi-tag 100 and the lo-tag 256.
A Activator tag
T Touchplate tag
L Locked activator tag
M Music and SFX tag
L+ Locator tag
C Cycler tag
D Master switch tag
R Respawn tag
Sp Speed tag
Bomb A sprite with the tile number 1247 (yellow
gasbottle), x-shrunken as narrow as possible. It
is intangible to the player, but blows up when
triggered.
6.1.2 Tags
6.1.3 Windows
6.1.4 A doorway
6.1.5 Angled surfaces
6.1.6 Glass panes
6.1.7 *Secret places*
To mark a sector secret, just tag it [0,32767]. A player will be
credited for finding it as soon as the sector is entered.
6.2 *Advanced editing*
6.2.1 *Cameras*
You can place cameras around the map, which will relay an image
to one or more viewscreens.
6.2.1.1 *Setup*
The security network consists of three objects:
Channels A channel transports the video data from the
camera(s) to the viewscreens. It is just a number.
## I haven't tested this thoroughly, but it seems
that the channel has to be a three-digit number.
Cameras (621) [Channel,Mobility]
They have to be sprites, and can be placed
anywhere in a room, facing in any direction. Using
the lo-tag, you can even set the camera mobility:
higher numbers allow the camera to move through a
wider arc.
Some example numbers:
0
Immobile
128
Very jerky (too short) - not recommended
256
Normal panning
Viewscreens (502) [Channel,0]
Viewscreens have to be sprites, too.
6.2.1.2 *Notes*
* If several cameras share a channel, the viewscreen
connected to this channel can cycle through all connected
camera views.
* It is advisable to hide the viewscreen behind armored
glass, to cause the well-known purple circles when it's
being shot at.
6.2.2 *Blastable walls (user control)*
Such walls can be blown up by detonating something close to them
(a pipebomb, RPG, etc).
6.2.2.1 *Setup*
* First build the wall with the hole already in it (usually
consisting of several sectors with angled floors and
ceilings).
* In each of these sectors, place an S [Channel,13].
On the wall to be blasted, place a (possible semi-
transparent) crack [Channel,0] (546-549), facing the
player. Fire extinguishers (916) can be used, too.
* If you want, place bombs on both sides of the wall for
realism [Channel,DelayUntilExplosion]. A delay of 8 is
very short, while 2000 takes ages before it explodes.
6.2.2.2 *Notes*
* A wall with a crack on each side will blow ok, but the
other crack will remain hanging in mid-air.
* Blastable walls retain no bullet holes until they blow.
* Usually, the angled floor and ceiling of the individual
sectors will line up ok, forming a solid wall. ##
Sometimes, however, they don't fit, creating triangular
holes in the (as yet unblasted) wall. Anybody know why?
6.2.2.3 *Tips*
* Use texture 852 (blasted concrete) on the inside of the
hole.
* Carefully align the wall textures. Especially the sideways
alignment is important, as the wall looks real bad if this
is not done properly.
6.2.3 *Blastable walls (triggered)
The work just like user-controlled blastable walls, except that
they can only be blown by program control, not by the user.
They are triggered by a T [0,Channel], and you can even add a
time-delay from the moment T is activated to the explosion of the
wall.
6.2.3.1 *Setup*
* First build the hole just as outlined above.
However, you won't need to place a crack.
* In just one of the hole sectors, add a D [Delay,Channel].
Delay ranges from 0 to 255, 255 being longest.
* Place at least a bomb [Channel, Delay] in the same sector
as D. Delay ranges from 8 (blow right away) to over 2000
(take ages, can be used for nasty traps) with typical
values being 8,16 or 32.
For realism, place some of these on both sides of the wall
as well.
* Place a T [0,Channel] in any sector. It will go off as
soon as the player enters the sector.
6.2.3.2 *Notes*
* You can blow several walls open simultaneously, but don't
use different delays - the world shakes, but the holes
only appear when the highest-numbered D blows.
6.2.4 Mirrors
6.2.5 *Light switches*
Light switches turn the light in one or more sectors on and off
('on' is very bright, 'off' is the original light level).
6.2.5.1 *Setup*
* Place a switch (eg 164) [0,Channel] sprite anywhere.
* The sectors to light up need an S [Channel,12].
6.2.5.2 *Notes*
* You can use several switches on the same channel, they
operate simultaneously.
* Switches work just fine if used on their own - perhaps
this could be used by players to communicate?
6.2.6 *Doors*
Ignoring simple doorways, real doors come in several flavours,
consisting of one or more moving sectors and some tags.
Note that all tags must be inside the door sector(s), not right
on the edge (turn off grid locking ond place it real close to the
edge, if necessary).
6.2.6.1 *Standard hinged*
A hinged door opens by rotation 90 degrees sideways.
The door sector [0,23] contains three tags:
S [11,Channel]
The location of the sector effector defines the
rotation axis, the direction the rotation
direction:
up
counterclockwise turn
down
clockwise turn
Sp [0,Speed]
Speed ranges from 8 (very slow) to over 1000 (real
fast). ## I think you can leave this sector away
for a default speed, but I'm not sure about this.
M [Sound2,Sound1]
Sound1 is the sound number to play when the door
is opened, Sound2 when it's closed. Usually, these
sounds will be the same.
*Notes*
* The doors floor texture doesn't rotate, but the ceiling
one does.
* Make sure that the door doesn't rotate out of its original
sector (for example, into a room with a higher ceiling) as
the graphics will mess up. Thus the sector containing the
door sector has to be large enough.
* You can open/close several doors simultaneously (building
double doors, for example) by allocating each door the
same channel.
6.2.6.2 *DOOM-type door*
This door opens by remote control (a switch) by raising the
ceiling from the floor, delays a moment, and lowers the ceiling
onto the floor again, closing the passageway.
*Setup*
* Switches (132) [0,Channel] can be placed anywhere. Must be
sprites.
* The door sector [0,20] contains 4 tags:
M [ClosedSound,MovingSound] (eg 0,167)
Sp [0,Speed] (eg 0,88)
S [OpenDelayTime,Channel]
A [0,Channel]
*Notes*
* Switches can be hidden by letting the sprites face the
wall and adding another sprite facing the player on top of
it (as done in the toilet of E1L2 with the blowdryer).
* If the door is half-open at game start, it will close
automatically.
* Don't make OpenDelayTime (the time to wait after closing
the door again) too short! A door with a value of 128 will
close real quick. If the time passes before the door has
fully opened, it will malfunction (could be used by
design, though).
6.2.6.3 *Sliding sideways*
This door works by moving/shrinking a sector sideways. A perfect
example of this can be found in E1L3 (Death Row), just to the
right of your starting point.
Building this door is easier to do than to explain, so bear with
me :) As soon as I have a better idea as to what exactly is
happening, I'll be able to explain this better...
Let's assume the door slides from the right into the left wall
when opening. We build the door in stages:
* The Entrance Sector, which contains the doorway.
First, we assign a sector (eg, connecting two rooms) which we'll
call the Entrance Sector. We're actually moving a sector
containing a one-sided wall, so the whole visible height will
move. This means that a sliding door is typically found in a low
passage, connecting two higher rooms.
* The Moving Sector.
Insode the Entrance Sector, insert two points below each other on
the left wall. From these, you now build a sector extending into
the Entrance Sector (in effect, the Entrance Sector will split
into an U-shaped Entrance Sector and a narrow moving sector)
[0,25].
* The door.
The door is actually made up of one-sided walls: insert two
points on the left wall inside the Moving Sector and pull them to
the right, creating the door itself.
You'll actually want to insert three points, creating a pointed
door which doesn't cover the Moving Sector completely but leaves
two wedge-shaped pieces open into which we'll add some tags:
* The tags.
S [Channel,15], facing right
M [DoneSound,MovingSound]
* The left wall
Insert two points on the left wall of the Entrance Sector: one
above the Moving Sector (call it P1) and one below it (call it
P2).
Now take the two inner points (the ones connecting the left wall
with the Moving Sector) a straight towards the left (not too
far), extending the Moving Sector in the process.
Finally, move P1 onto the upper line of the door and P2 ontoo the
lower one.
Phew! Looks weird, because so many unconnected lines and points
are overlaying each other (obviously, you should work with Grid
Lock on) but it should work.
*Notes*
* A typical sliding door texture is 447.
* So far, I've only gotten this door to open half-way ##.
Evidentially, there's an additional, flat sector involved
(see e1L3), but I haven't gotten it to work yet.
* Changing the heading of the sector effector produces
interesting (and usually, buggy) results.
6.2.7 *Shrinking sector (remote control)*
This will shrink a sector (for example a curtain) by on the press
of a button. ## I haven't gotten the sector to regrow, however.
6.2.7.1 *Setup*
* Place one or more switches anywhere
[ActivationSound,Channel].
* Inside the sector to shrink [0,27], place three tags:
S [Channel,20] facing the movement direction.
A [0,Channel]
Sp [0,Opening Speed]
6.2.8 Elevators
6.2.9 *Teleporters*
Teleporters move players instantly between any two points.
6.2.9.1 *Setup*
Teleporters are not sectors, but simply sector effectors. They do
need the floor tile 626, though:
S [7,Channel], facing is the same the arriving player should
face.
6.2.9.2 *Notes*
* A teleporter without a floor tile 626 only act as
receivers.
* A single teleporter without a destination will kill the
player.
* When usgin more than two teleporters on the same channel,
you always land on the teleporter with the lowest sprite
number. If teleporting from the lowest sprite number, you
end u on the next-highest one.
* Teleporters don't work if you fly over them.
* ## I've had strange effects when firing rockets into two
teleporters set up in a line - the rocket reappeared
_behind_ me, angled slightly to the right (thankfully :)
Any ideas?
6.2.10 *Swimming pools*
Swimming pools allow the player to jump into the water and dive
around under the water surface.
6.2.10.1 *Setup*
A swimming pools consists of at least two sectors: one is the
room above the water, one is the room below it. An teleporter
secretly moves the player (and any other objects, like pipebombs)
between the levels as required.
The sectors sharing the water surface have to be the exact same
size and shape (of course).
The teleporter connecting them needs a unique channel number.
Above-water sector
[0,1]
S [Channel,7]
Below-water sector
[0,2]
S [Channel,7]
6.2.10.2 *Notes*
* The floor/ceiling types for the water surface don't matter
- all objects will always be transported correctly, water
will splash, etc.
This allows you to generate hidden traps, mud, etc.
* If you split a pool into several sectors (for example in
order to create a pool with a shallow and a deep end), you
have to split the above-water sector as well and add a
sector effector in each new sector.
6.2.10.3 *Tips*
* Nothing to stop you from adding sector to the below-water
sector, forming an underwater tunnel leading somewhere
else; perhaps even surfacing in a different pool.
6.2.11 The Grapplers
6.2.12 Floors above floors
6.2.13 Morphing ramps
6.2.14 *Vehicles*
## I haven't yet managed a subway - they always turn into
attacking vehicles (next section).
6.2.15 *Attacking vehicles*
Vehicles (simply a sector with a raised floor) can be set up to
travel from their original position to a pre-determined closed
path, which they will follow, attacking any visible player with
rockets (like the space fighter at the start of E2L1).
6.2.15.1 *Setup*
* The vehicle sector requires an S [0,6]. The position of
this tag determines the rotation center when turning, and
its direction the facing of the vehicle.
* Mark the route with several L+ [Pause,VisitingOrder].
A Pause of 0 means smooth movement, a 1 means a short
pause at the _next_ L+.
The tags are visited in their VisitingOrder, starting from
0.
6.2.15.2 *Notes*
* The vehicle must start in the same sector as its route, as
the game will reuse to run otherwise. Thus you can't, for
example, cause a car to come out of a low garage and
circle around outside afterwards.
* You can have several vehicles following the same route.
* You can also design a vehicle using several sectors, but
they will rotate individually at each L+. Rather use a
'bounding' sector, containing the S.
6.3 Tips and tricks: New and interesting effects
Chapter 7
Programming the .CON files
Chapter 8
Utilities and add-ons
8.1 Editing utilities
8.2 Data files
8.2.1 Graphics
8.2.2 Sounds
8.2.3 Music
8.2.4 .CON modifications
8.2.5 Demos (Recordings)
8.2.6 Missions
8.2.6.1 *GRP Authoring Template v0.1*
Note that I've simply taken and modified the v1.4 of the
"Official" GRP Authoring Template - ## any objections?
For all of you map authors out there, here is the "Official" GRP
Authoring Template v0.1. When you release your map, please fill
this form out and place it in the information file you create
about your new map. This way we'll easily be able to compare
submissions.
Thanks to Steve Bareman (bareman@hope.cit.hope.edu) for creating
a WAD about file standard.
GRP Authoring Template V0.1 (Clip this line)
================================================================
Title :
Filename : xxxx.MAP
Author : Your name here
Email Address :
Misc. Author Info :
Description : Set the mood here.
Additional Credits to :
================================================================
* Play Information *
Episode and Level # : ExMx (,ExMx,...)
Single Player : Yes/No
Cooperative 2-8 Player : Yes/No
Deathmatch 2-8 Player : Yes/No
Difficulty Settings : Yes/Not implemented
New Sounds : Yes/No
New Graphics : Yes/No
New Music : Yes/No
New Programming : Yes/No
Demos Replaced : None/1/2/All
* Construction *
Base : New level from scratch/Modified
ExMx/xxx.MAP
Editor(s) used :
Known Bugs :
* Where to get this map *
FTP sites:
BBS numbers:
Other:
8.3 *Future add-ons*
8.3.1 *Add-on software wish list*
Attention programmers! Here is a wish list, created by the DN3D
players, of add-on software that should be made for DN3D. If you
would like to make an addition to this list, please send me E-
mail.
Additionally, if you are planning on creating one of these
utilities, tell me, and I'll move it to the "Add-on software in
the making" chapter.
* A DEU-like pre-editor for the rough work (to be fine-tuned
later by BUILD.EXE). Ideally, this preeditor would be
network-capable to allow several people to work on a level
simultaneously.
* Automatic .CON file patcher to allow easy inclusion of
.CON modifications.
* Lots of additional graphics, allowing the building of
realistic 'normal' street and house maps.
8.3.2 (Add-on software in the making)
This chapter tells about add-on software which is being currently
worked on.
If you are working on something that is not in here, please send
me E-mail so I can put it in.
In this section, you can also request help on creating some add-
on software.
Chapter 9
Troubleshooting
9.1 Bugs in the game
9.1.1 Remote switch triggering
9.1.1.1 *Bug*
If a switch is placed on a thin wall, you can trigger it from the
other side of the wall.
9.1.1.2 *Workaround*
Place switches on thicker or even outside walls.
9.2 Bugs in BUILD
9.2.1 *'G'oto Tile*
9.2.1.1 *Bug*
When pressing 'V' in 3D mode to select a texture, pressing 'G' to
immediately jump to a certain tile number will sometimes hang the
game.
9.2.1.2 *Workaround*
When selecting a texture, always press 'V' twice, jumping to the
complete tile list.
9.2.2 *Selecting long lines*
9.2.2.1 *Bug*
If a line is too long, you can't select it anymore by moving the
curser near it. Thus you also can't insert new points on it, for
example.
9.2.2.2 *Workaround*
Keep the lines short by inserting points on too long olines:
shorten the line, insert a point, lengthen the line again, move
the newly inserted point into the middle of the line.
Chapter 10
*Reference lists*
This chapter contains useful reference material which you might
even want to print out and keep handy while designing levels.
10.1 *List of tiles*
Hre's a complete list of all sector tags, with a detailed
explanation on each:
10.2 *List of tiles*
This section contains a list of all tiles in the game, sometimes
with a short explanation.
513 Bridge sprite
Used to create a walkable bridge like in E1L1 near
the exit.
852 Broken concrete
Typically used inside blasted holes or damaged
walls.
Chapter 11
*Miscellaneous*
11.1 *Conclusion*
Phew! Well, that is all I have! I hope this FAQ proves to provide
a good resource for DN3D Editing information. If you have any
suggestions, questions, additions, or comments for the FAQ, send
me e-mail at "sz0759@rrze.uni-erlangen.de".
Thanks for reading the FAQ! -Klaus Breuer
SUPPORT YOUR SHAREWARE COMPANIES! REGISTER YOUR SHAREWARE!
11.2 *Revision history*
v0.1 First release of the DN3D EDITING FAQ as an RFC.
(16. May 1996)
v0.2 RFC II, added how-tos and changed the format a
bit. (20. May 1996)
Contents
Chapter 1 Happy lawyer dept. 3
1.1 Disclaimer . . . . . . . . . . . . . . . . . 3
1.2 Trademark information . . . . . . . . . . . . 3
1.3 Copyright notice . . . . . . . . . . . . . . 3
Chapter 2 Introduction 5
2.1 *A word from Klaus Breuer* . . . . . . . . . 5
2.2 *About the "UnOfficial" DUKE NUKEM 3D EDITING
FAQ* . . . . . . . . . . . . . . . . . . . . 5
2.3 *Getting the "UnOfficial" DN3DE FAQ* . . . . 6
2.4 (Adding to the FAQ) . . . . . . . . . . . . . 6
2.5 (The DN3D EDITING mailing list) . . . . . . . 7
2.6 (Acknowledgments) . . . . . . . . . . . . . . 7
2.7 (Accurate information) . . . . . . . . . . . 7
2.8 *Help with new levels* . . . . . . . . . . . 8
Chapter 3 Preliminary information 9
3.1 Intended audience for this chapter . . . . . 9
3.2 The basics . . . . . . . . . . . . . . . . . 9
3.3 What a map consists of . . . . . . . . . . . 9
3.4 BUILD basics: the BUILD.EXE editor . . . . . 9
3.5 2D mode . . . . . . . . . . . . . . . . . . . 9
3.5.1 Creating a new sector . . . . . . . . . 9
3.5.2 Creating an internal sector . . . . . . 9
3.5.3 Erasing a sector . . . . . . . . . . . . 9
3.6 3D mode . . . . . . . . . . . . . . . . . . . 9
Chapter 4 Planning and designing a level 11
4.1 Before starting . . . . . . . . . . . . . . 11
4.2 Pros and cons of using real-world maps . . 11
4.3 *Typical mistakes to avoid* . . . . . . . . 11
4.3.1 *Crossed lines* . . . . . . . . . . . 11
4.3.2 *Overlaying lines* . . . . . . . . . . 11
Chapter 5 A walkthrough to creating a simple level 13
5.0.1 Some thoughts on good level design . . 13
5.1 Creating a new map . . . . . . . . . . . . 13
5.2 The grid . . . . . . . . . . . . . . . . . 13
5.3 Creating a room . . . . . . . . . . . . . . 13
5.4 Changing the floor and ceiling heights . . 13
5.5 Changing the look of walls (textures) . . . 13
5.6 Adding another room . . . . . . . . . . . . 13
5.7 Adding a pedestal (inner sectors) . . . . . 13
5.8 Sprites and objects . . . . . . . . . . . . 13
5.9 The enemy appears . . . . . . . . . . . . . 13
5.10 Player starting points . . . . . . . . . . 13
5.11 Save-n-go . . . . . . . . . . . . . . . . 13
Chapter 6 How to... 15
6.1 *The basics* . . . . . . . . . . . . . . . 15
6.1.1 *Abbreviations* . . . . . . . . . . . 15
6.1.2 Tags . . . . . . . . . . . . . . . . . 16
6.1.3 Windows . . . . . . . . . . . . . . . 16
6.1.4 A doorway . . . . . . . . . . . . . . 16
6.1.5 Angled surfaces . . . . . . . . . . . 16
6.1.6 Glass panes . . . . . . . . . . . . . 16
6.1.7 *Secret places* . . . . . . . . . . . 16
6.2 *Advanced editing* . . . . . . . . . . . . 16
6.2.1 *Cameras* . . . . . . . . . . . . . . 16
6.2.1.1 *Setup* . . . . . . . . . . . . . 16
6.2.1.2 *Notes* . . . . . . . . . . . . . 17
6.2.2 *Blastable walls (user control)* . . . 17
6.2.2.1 *Setup* . . . . . . . . . . . . . 17
6.2.2.2 *Notes* . . . . . . . . . . . . . 17
6.2.2.3 *Tips* . . . . . . . . . . . . . 17
6.2.3 *Blastable walls (triggered) . . . . . 18
6.2.3.1 *Setup* . . . . . . . . . . . . . 18
6.2.3.2 *Notes* . . . . . . . . . . . . . 18
6.2.4 Mirrors . . . . . . . . . . . . . . . 18
6.2.5 *Light switches* . . . . . . . . . . . 18
6.2.5.1 *Setup* . . . . . . . . . . . . . 18
6.2.5.2 *Notes* . . . . . . . . . . . . . 18
6.2.6 *Doors* . . . . . . . . . . . . . . . 19
6.2.6.1 *Standard hinged* . . . . . . . . 19
6.2.6.2 *DOOM-type door* . . . . . . . . 19
6.2.6.3 *Sliding sideways* . . . . . . . 20
6.2.7 *Shrinking sector (remote control)* . 21
6.2.7.1 *Setup* . . . . . . . . . . . . . 21
6.2.8 Elevators . . . . . . . . . . . . . . 22
6.2.9 *Teleporters* . . . . . . . . . . . . 22
6.2.9.1 *Setup* . . . . . . . . . . . . . 22
6.2.9.2 *Notes* . . . . . . . . . . . . . 22
6.2.10 *Swimming pools* . . . . . . . . . . 22
6.2.10.1 *Setup* . . . . . . . . . . . . 22
6.2.10.2 *Notes* . . . . . . . . . . . . 23
6.2.10.3 *Tips* . . . . . . . . . . . . . 23
6.2.11 The Grapplers . . . . . . . . . . . . 23
6.2.12 Floors above floors . . . . . . . . . 23
6.2.13 Morphing ramps . . . . . . . . . . . 23
6.2.14 *Vehicles* . . . . . . . . . . . . . 23
6.2.15 *Attacking vehicles* . . . . . . . . 23
6.2.15.1 *Setup* . . . . . . . . . . . . 23
6.2.15.2 *Notes* . . . . . . . . . . . . 23
6.3 Tips and tricks: New and interesting
effects . . . . . . . . . . . . . . . . . . 24
Chapter 7 Programming the .CON files 25
Chapter 8 Utilities and add-ons 27
8.1 Editing utilities . . . . . . . . . . . . . 27
8.2 Data files . . . . . . . . . . . . . . . . 27
8.2.1 Graphics . . . . . . . . . . . . . . . 27
8.2.2 Sounds . . . . . . . . . . . . . . . . 27
8.2.3 Music . . . . . . . . . . . . . . . . 27
8.2.4 .CON modifications . . . . . . . . . . 27
8.2.5 Demos (Recordings) . . . . . . . . . . 27
8.2.6 Missions . . . . . . . . . . . . . . . 27
8.2.6.1 *GRP Authoring Template v0.1* . . 27
8.3 *Future add-ons* . . . . . . . . . . . . . 28
8.3.1 *Add-on software wish list* . . . . . 28
8.3.2 (Add-on software in the making) . . . 29
Chapter 9 Troubleshooting 31
9.1 Bugs in the game . . . . . . . . . . . . . 31
9.1.1 Remote switch triggering . . . . . . . 31
9.1.1.1 *Bug* . . . . . . . . . . . . . . 31
9.1.1.2 *Workaround* . . . . . . . . . . 31
9.2 Bugs in BUILD . . . . . . . . . . . . . . . 31
9.2.1 *'G'oto Tile* . . . . . . . . . . . . 31
9.2.1.1 *Bug* . . . . . . . . . . . . . . 31
9.2.1.2 *Workaround* . . . . . . . . . . 31
9.2.2 *Selecting long lines* . . . . . . . . 31
9.2.2.1 *Bug* . . . . . . . . . . . . . . 31
9.2.2.2 *Workaround* . . . . . . . . . . 32
Chapter 10 *Reference lists* 33
10.1 *List of tiles* . . . . . . . . . . . . . 33
10.2 *List of tiles* . . . . . . . . . . . . . 33
Chapter 11 *Miscellaneous* 35
11.1 *Conclusion* . . . . . . . . . . . . . . . 35
11.2 *Revision history* . . . . . . . . . . . . 35
---
Klaus Breuer, Rudelsweiher Str. 6b, 91054 Erlangen, Germany
"Geez, I need a *reason* for everything?" -- Calvin
"Should I or shouldn't I? Too late, I did!" -- Hobbes
